“日用到底应不应该开启 HDR ”、“ 为什么显示器开启 HDR 之后颜色不正”这种简单的问题往往能水出个十条八条，甚至还能有人就因为这个吵得不可开交，今一睡醒逛逛某坛又看到有人在吵这破玩意，抱着“住手，你们不要再打啦！”的心态，准备写点东西来纠正一下几个常见的误区，争取让大家都把这个问题想明白。也希望以后再有这种破事水的帖子能一个链接甩过去终结话题，别再是两三页下来都是俩人试图用各自奇怪的经验论说服对方了。

要想捋清楚“为什么开启 HDR 之后颜色会变”，我们总得先知道「什么是 HDR 」，以及「在启用 HDR 之后，显示系统是如何工作的」。

「HDR 到底是高亮度还是高对比度」这个话题是另一个大战场，要是大伙有兴趣后面可以展开聊聊，这里就按下不表了。对于不同的设备和场景而言，HDR 在技术上的实现方式有非常大的差异，从不同的角度可以给出截然不同的回答。但我要说的是：

对于显示器而言，输入的信息就是且仅是三条 0 ~ 1 的归一化信号，在这里，HDR 和峰值亮度、对比度和色域都没有任何关系，纯粹就是 EOTF (传统 SDR 观念里的 Gamma) 的差异。

考虑到实际软硬件支持的情况，在当下这个时间节点，你甚至可以认为显示器启用 HDR 之后，就仅仅是把 Gamma 给切换成了 PQ , 其它的工作都是在系统端依靠软件完成的。

——在启用 HDR 之后，显示系统是如何工作的 ？

对于 Windows 而言，这个过程是把输出的信号变成了全局的 PQ ST.2084 / Rec.2020 信号。 因为不存在可以输入、处理 SDR 和 HDR 的混合信号的显示设备，所以当需要显示 HDR 内容时，系统发送的信号在输入显示器前，就必须是全局的 SDR 或 HDR 信号。但从现实意义上出发，需要显示的所有内容必然不可能都是 HDR 素材，所以当你在系统里打开 HDR 时，实际上需要进行的是三步操作：

识别窗口的 tag , 区分素材是 SDR 还是 HDR

2.把所有素材上变换进 ST.2084 / Rec.2020

3.以全局 ST.2084 把最终的画面发送给显示设备

显然，最大的误会就出在了这里：SDR 素材是如何上变换进 HDR 的？

——SDR 素材是如何上变换进 HDR 的？

正如前文所提，在 HDR 下，系统发送的信号是全局 PQ / Rec.2020 的......于是部分坛友就想当然地认为：发灰说明显示器不行，信号是全局 PQ / Rec.2020 的，显示器也得满足峰值亮度 10000 尼特 / BT.2020 全覆盖才能正常显示吧？

如果你以前也是这么想的，那么认识一下“什么是色彩管理”以及“什么是 HDR ”都会对你理解接下来的内容有很大帮助。

色彩管理的本质就是统一不同“尺子”的度量衡 ——

假设有这么一台 EOTF 跟踪十分标准的，白点亮度 400 尼特的显示器 A . 10 尼特对于该设备的 SDR 模式而言位于约 18% 灰；在 HDR 下，相同的 10 尼特则位于约 30% 灰，“色彩管理”需要做的工作，就是通过数学的手段，把原本的 18% 变换为 30% 灰。

而且 ST.2084 是基于绝对亮度的：在传统 SDR 的思维里，白点亮度为 400 尼特的显示器 A 和白点亮度为 10000 尼特的显示器 B , 显示的 "50% 白" 显然是不同的。但在 PQ 里，不管白点是 400 尼特还是 10000 尼特，50% 白总是约 90 尼特。

所以不管设备是 45% NTSC 还是 100% Rec.2020 , 不管设备的白点是 100 尼特还是 10000 尼特，出现“发灰”、“褪色”的情况都和设备的显示能力没有任何联系 —— SDR 下该怎么显示，在实现了正确的上变换时，HDR 下就应该怎么显示。

回到具体的问题。Windows 的上变换依靠的是通过 EDID 来获得设备的的色域和最高亮度，并根据设备的实际信息来做的上变换。但是由于系统并没有办法抓取显示设备的 HDR EOTF （其实 ICC profile 逻辑上是包含设备完整的 EOTF 信息的，但 HDR 的 ICC 和 MHC2 是另一个大坑，后面有机会可以唠两句） 所以不论显示设备的 HDR EOTF 实际长什么样，都会被当作绝对跟随 Hard Clip 来进行最终的上变换处理。

——按你说的 45% NTSC 也不会发灰，为什么我的显示器打开 HDR 就发灰？

因为目前的绝大多数素材都是 SDR 的，所以“发灰”的设备在启用 HDR 之后通常会发现整个屏幕显示的所有内容都是“发灰”的。

首先要做的是确认问题发生在哪一个环节。在前文我提到过 HDR 下的工作机制。由于原本就是 ST.2084 / Rec.2020 的素材并不会进入上变换的管线，且 Windows HD Color 存在一个独立调整 HDR 下 SDR 素材亮度的滑块，我们可以通过这两个功能的组合来判断当前素材有没有经过 Windows 的上变换，从而确认“发灰”的是全局所有内容，还是经上变换的 SDR 素材。

启用系统的 HDR 并打开一部 HDR 电影，并移动 SDR 的亮度滑块，确认右侧的电影亮度是否改变。如果电影亮度发生了变化，那么说明电影进入了 SDR 的变换管线，需要更换播放器直到电影亮度不变（建议用 Windows 电影与电视或者 VLC）

如果亮度稳定的 HDR 电影也是严重"发灰"的，那么说明系统输出了全局的 HDR 信号，但显示设备没有完成自动握手，仍然处于 SDR 模式。如果显示器可以手动切换到全局的 HDR 模式，检查切换之后是否还存在发灰的现象。

——如果 HDR 的电影颜色正常，只有原先的 SDR 素材发灰呢？

Windows 的上变换依靠的是通过 EDID 来获得设备的的色域和最高亮度，并根据设备的实际信息来做的上变换。

说明“发灰”的问题是上变换的过程中造成的。EDID 可以理解驱动板向系统的声明：它包含了非常多的信息，但这些信息是需要工程师在固件开发时手动填入的。虽然系统会通过 EDID 抓取设备的实际信息，但如果信息本身就是错误的，那自然后续的上变换过程都是有问题的。

即使 SDR 素材的上变换过程出现了问题，但 HDR 素材仍然是可用的。所以这类设备平时用用 SDR , 在需要看 HDR 内容时再启用 HDR …… 也不是不能用？

回到今天看的那个帖子，「在能正确处理HDR的显示器上，是没有任何变化的。」这个观点正确吗？

显然是错误的。对于显示设备而言，只要能输入 HDR 信号，就算是“能正确处理 HDR ”了。支持 HDR 的驱动板，指的就输入 HDR 信号不会黑屏。甚至于显示器实际上不存在“处理 HDR ”的这个过程，信号的处理都在系统端完成，要实现「启用 HDR 之后发色正常不出问题」，显示器需要做的只是填对 EDID 和在识别到 HDR 信号后自动握手，和显示设备的 HDR 能力（亮度、对比度、色域覆盖）没有任何关联。这里打个补丁，如果你的系统还是 win 10 刚支持 HDR 的早期版本......当时的上变换管线没有完全做好，不管显示器怎么努力都是会发灰的，Windows 要 HDR 至少需要把系统更新到 1809

但如果要实现「启用 HDR 之后 SDR 内容没有任何变化」...... 那很不幸的是，从原理上就不存在这样的设备：把 SDR 的内容上变换进 HDR 的过程, 必然是会丢精度的。这是一个显而易见的数学问题，所以在 HDR 下的 SDR 表现，必然没有系统 SDR / 显示器 SDR 信号对齐时来得好。

另一个问题在于...... 一些 HDR 400 的显示器如果在低亮度下严格遵循 Hard Clip , 那么很可能在 HDR 下的细节还没有 SDR 来得多。但 Windows 强制以标准 PQ EOTF 来做上变换的特性意味着如果在低亮度下进行一定的 roll off , 系统 HDR 下的 SDR 可用性会变得十分糟糕。

综上所述，我认为尽量让信号对齐，在 SDR 下看 SDR , HDR 下看 HDR 仍然是体验最好的。当然，如果设备在 HDR 下的损失你自身可以接受，那么省一步切换的操作全局 HDR 也没啥问题。显示器是给自己用的，怎么舒服怎么来。